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(54) Disease management method and system 

(57) The Disease Management system and method 
Includes a Patient Medical information source (100). a 
Predictive l-lealtii Outcome Modeling process (102), a 
process for Inten^ention of At-risk Patients (103), and a 
source of disease management Modeling Guidelines 
(104). The Patient Medical Information source (101) is a 
database containing medical records of patients who 
participate in a healtiicare provider's program. The Pre- 
dictive IHealth Outcx)me Modeling process (102) pro- 
duces a statistical model used to predict whether a 
patient with a particular disease is likely to suffer an 
adverse healtfi outcome. The Intervention of At-risk 
Patients process (103) derives a list of at-risk patients 
who have a high risk of suffering an adverse healtii out- 
come and intervenes in the selected patient's healtii- 
care treatment to decrease ttie possibility of such an 
adverse health outcome. The Predictive Healtii Out- 
come Modelling process (102) 1) receives a sample 
group of patient medical data from ttie Patient Medical 
lnformatk)n database (100) for a given disease. 2) 
receives pre-determined statistical infbrmation for gen- 
erating predictive models, shown as tiie Modeling 
Guidelines (104), and 3) generates a particular predic- 
tive model for a particular disease to determine ttie 
proisability of an adverse health outcome. The Interven- 
tion of At-risk Patients process (103) 1) receives ttie 
predictive model provided by ttie Predictive Health Out- 
come Modeling process (102), 2) analyzes ttie individ- 
ual patient specific medical data from the Patient 



Medical Infbrmation database (100). and 3) identifies a 
list of current patients that are at-risk of an adverse 
healtti outcome for a particular disease. The Interven- 
tion of At-risk Patients (103) process Inten/enes in ttie 
treatment process of the patients contained in ttie 
patient list through contact witti ttie patient, physician, or 
healtiicare provider, and the process requires externally 
generated infbrmation about tteatment regimens for 
given stages of disease progression, as well as particu- 
lar Interventions. 
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Description 

FIELD OF THE INVENTION 

[0001 ] This Invention relates to electronic computational processing techniques in the field of human healthcare and, 
more particularly, to identification of high-risk patients fa disease and disease Intervention management using various 
electronic computational processing techniques. 

BACKGROUND OF THE INVENTION 

[OOMJ Diseases or condition can be more effectively and more cost-effectively treated by designing a program to 
maximize compliance witii current best medical practices which are also consistent with a given prefen-ed treatment 
regimen and on a case by case basis. Treatment for many types of diseases has moved from episodic, synptomatic 
treatment to disease reduction and prevention. 

[0003] Healthcare costs in general are rising rapidly, and. in many cases, the costs of treating patients is not distrib- 
uted evenly among the total population of patients because it costs more to treat some patients tiian others. This is 
partiy due to some patients not receiving appropriate therapies for ttieir medical condition. This problem has several 
causes, including that some patients do not comply with ttieir presaibed treatment regimens, ttiat some patients do not 
visit their doctors at appropriate times, and. in some cases, that some doctors are not aware that a certain tiierapy reg- 
imen is mae likely to be more effective tiian their current regimen. 

[0004] If patients are treated in aocordance with therapy regimens proven to be effective for a given state of disease 
progression, tiien the total costs of treating the whole population will decline. If more patients are treated property, ttien 
the number of cases which progress to mae serious stages of disease, which are more oostiy to treat, will he reduced. 

SUMMARY OF THE INVENTION 

[0005] The present invention is a computer-implemented system and method for identifying at-risk patients, particu- 
larly those diagnosed with an identified disease, where the infamation about patients is extracted from at least one pre- 
existing in at least one database. The system includes a means for processing tiie patient Infamation in ttie database 
based on a predetermined criteria to extract relevant information for a group of patients having or who may develop tiie 
klentif ied disease. The system defines a predictive model, including associated rules, by: 

a) processing, based on predetermined aiteria. ttie patient infamation in ttie database to extract patient informa- 
tion for a group of patients relating to an identified disease a condition: 

b) defining a predictive model including: 

i) defining, using the infamation available in the database, a set of events a data relevant to the kJentif led dis- 
ease or condition; 

ii) converting tiie extracted patient infbrmation and tiie defined events a data Into f ies comprising event-level 
information; 

liQ defining a time-window for provkJing a timeframe from which to judge whether specific ones of the defined 
events should be consklered in sut>sequent processing; 

iv) identifying a set of variables as potential predictors; 

v) processing the event-level Infamation. using ttie time^ndow and the set of variables, to generate an anal- 
ysis file; 

vi) performing statistical analysis on the analysis file to generate the predk:tion model and a set of rules for use 
in kfentifying at-risk patients diagnosed witii or who may develop the identified disease a condition, said pre- 
diction model and rules being a function of a subset of the set of variables; 

c) applying the prediction nxxiel and the ailes to the same a new set of event-level infamation to identify at-risk 
patients fa the identified disease a condition, a to identify patients who may be at risk fbr developing tiie identified 
disease or condition; 

d) preparing an interventton list from the identified at-risk patients and selecting, fa at least one at risk patient an 
intervention; 

e) distributing or facilitating the distribution of the intervention to said patient; and optionallyO recording and backing 
an intervention result for each at-risk patient based on the respective selected intervention; and optionally 

g) updating tiie historical data in at least one database wltti each Intervention result corresponding to sakJ data- 
base; and 
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repeating step b(ii). and 

h) re-applying the prediction model and rules to the event-level information extracted from the data in the updated 
database. 

5 BRIEF DESCRIPTION OF THE DRAWINGS 

[0006] The invention is best understood from tiie following detailed description when read in connection witfi the 
accompanying drawing, in which: 

10 Figure 1 A is a high level diagram of the Disease Management System of the present invention 

Rgure 1 B is a high level flowchart illustrating an exemplary overall process of tiie Disease Management System of 
the present invention. 

Rgure 2A is a high level flowchart illustrating the raw patient data acquisition, pre-processing, and database forma- 
tion of tiie present invention. 

IS Figure 2B is a high-level block diagram illustrating three exemplary sources of Information suitable for use with the 
present invention. 

Rgure 3 is a flowchart of an embodiment of the conversion process of the Raw Patient Data Pre-processing proc- 
ess of tiie present invention. 

Rgure 4 is an illustration of an exemplary Data Model as used in the Disease Management database of an embod- 
20 iment of the present invention. 

Rgure 5 is a diagram illustrating the research database format fa each of the Rx. DR, and HL claims of the records 

contained in the research database of an exemplary embodiment of the present invention. 

Rgure 6 is a high level flowchart illusf ating the Extraction process and Predictive Modeling process for an identified 

disease of the present Invention. 
25 Rgure 7A is a diagram illustrating an event level file of one embodiment of the present invention generated for 

depressfon as the identified disease. 

Rgure 7B is a diagram Illustrating an event level file of one embodiment of the present invention generated Ibr con- 
gestive heart feilure as the identified disease. 

Rgure 8 is a diagram illustrating the format of tiie analysis file of one embodiment of the present invention fbr an 
30 identified disease. 

Rgure 9 is a time-line diagram showing the events and prediction window scheme as used in the present invention. 
Rgure 1 0A is a time-line diagram which shows a f irst exenplary time window scheme suitable fbr use in processing 
the data from the event level files shown in Rgure 7A and Figure 7B. 

Rgure 1 0B is a time-line diagram which shows a second exemplary time window scheme suitable for use in 
35 processing the data from the event level files shown in Rgure 7A and Figure 7B. 

Rgure 11 is a high level flowchart showing the Risk Stratification process of ttie present invention including ttie 
Front End process and the Mining Engine process to generate an intervention list for an identified disease. 
Rgure 12 is a high level flow chart showing the Mining Engine of tiie Risk Stratification process of the present 
invention. 

40 Rgure 1 3 is a high level diagram of the Intervention Management process of the present invention. 
DETAILED DESCRIPTION OF THE INVENTION 
General Overview 

45 

[0007] The Disease Management system and method of the invention increases the number of patients within a given 
population who receive, comply with, and con'ectiy administer appropriate therapies for treating a disease or condition. 
The invention requires identifying preferred treatment regimens for given stages of disease progression. These regi- 
mens may be published medical guidelines or guidelines developed by healthcare professionals for a given type of dls- 

50 ease. These gukjellnes are called Best Practice Guidelines. 

[0008] The \em "disease management" applies to, for ©(ample, managed care organization, medical group, 
employer, or government sponsored programs that identify individual patients with chronic long term conditions that 
may be at risk of expensive hospitalization or other high cost events or adverse health outcome. Disease management 
services are defined by a research area in conjunction with product development managers who serve as disease sub- 

55 ject matter experts. 

[0009] Disease management services are offered to clients (participating managed care organizations (MCOs) or 
other types of subscribers) for ttie purposes of early intervention at specific disease states to improve future disease, 
outcomes. An indlviduaFs medical, clinical and administrative medical history information is provided from, for exanrple. 
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third party processors to the disease management system. 

[0010] This specification primarily describes use of the Disease Management system of the present invention with 
regard to the healthcare field in which healthcare providers are the primary clients of the system, and information about 
the patients of these healthcare providers are provided to a database for the practice of the invention. However, it is con- 
5 templated that other embodiments of the invention include other types of clients, such as employers, government agen- 
cies, insurance providers, or other users who are interested in disease management or the thriftiness of a given 
population of individuals. Similarly, the information provided to the database of the Disease Management system could 
be expanded to include demographic data, socialization, geographic data, family history, or other information about an 
individual. 

10 [001 1 ] A basic disease management system will look at one disease or condition. But multiple diseases or conditions 
can be factored into a single analysis and thereby develop a risk profile based on multiple factors and multiple diseases 
or conditions. In essence, the approach is to view each disease or condition as a module which can be cross-referenced 
like the fields of a relational data base. That permits the analyst to draw on more than one disease or condition in devel- 
oping a risk factor for a given patient population. 

75 [0012] Refemng to Figure 1 A. the high level diagram of the disease management process of the present invention 
includes a Patient Medical Information source 100, a Predictive Health Outcome Modeling process 102, a process for 
Inten^ention of At-risk Patients 103. a source of disease management Modeling Guidelines 104. and a source of Inter- 
vention and Medical Guidelines 105. The process for Intervention of At-Risk Patients 103 has two parts: a Risk Strati- 
fication process 140 and an Intervention Management process 160. TTie Patient Medical Information source 101 is 
,20 typically a form of database containing, for example, records of medical histay. physical descriptions, psychiatric 
records, laboratory tests results, oognitton and intelligence test data, prescriptions and treatment of patients who par- 
ticipate in a healthcare provider's program. 

[0013] The Predictive Health Outcome Modeling process 102 of Figure 1A is a process that produces a statistical 
model which can be used to predict whether a patient with a particular disease or condition and medical history is likely 

25 to suffer an adverse health outcome. The process of Intervention of At-risk Patients 1 03 includes: the Risk Stratification 
process 140 that is a database analysis process which derives a list of at-risk patients who have a high risk of suffering 
an adverse health outcome, and the Intervention Management process 160 that determines an intervention In the 
selected patient's healthcare treatment to decrease the possibility of such an adverse health outcome. 
[0014] The operation of ttie disease management process of the present invention, as shown in Rgure 1 A, is now 

30 desaibed. Rrst. the Predictive Health Outcome Modeling process 1 02 receives a sample group of patient data from the 
Patient Medical Informatbn database 100 for a given disease. In addition, the Predictive Health Outcome Modeling 
process 102 receives certain pre-determined statistical or other information for generating predictive models, shown as 
the Modeling Guidelines 1 04 in Figure 1 A. and generates a particular predictive model for a particular disease to deter- 
mine the probability of an adverse health outcome. The same or similar data couki be used to determine tiie probability 

35 of developing a particular disease or condition whk;h is associated with an adverse health outooma 

[001 5] The Risk Stratification process 1 40 receives the predictive model provMed by the Predk^e HeaHh Outcome 
Modeling process 102 and analyzes the individual patient-specific data from the Patient Medical Information database 
1 00 witti the predictive model to identify a list of curent patients that are at-risk of an adverse healtfi outcome for a par- 
ticular disease. Once the list of patients is identified, the Intervention Management process 160 suggests an Interven- 

40 tion in the treatment process of the patient tiirough contact with ttie patient physician, or healthcare provider. The 
process of Intervention of At-risk Patients 1 03 requires externally generated information about treatment regimens (e.g. 
Best Practice GukJelines) for given stages of disease progression, as well as particular inten^entions, whk:h are shown 
as the Intervention and Medical Guidelines 105 of Figure 1 A. 

[0016] Finally, the interventions itself may be recorded, and once the process of Intervention of At-risk Patients 103 
45 has been completed, the results of these inten/entions. shown as intervention outcome measurements in Figure 1 A. are 
recorded In the Patient Medk»l Information database 1 00. This allows for a feed-back step where data after intervention 
can be fed back through tiie whole process, either to be again re-run through the Risk Stratif fcation step to help analyze 
the outcomes or to become part of the basis for generating a new and revised Risk Stratification process. 
[0017] To summarize, tiie disease management system analyzes ttie flow of incfivkjual. patient-spedfk: health infor- 
50 mation and intervenes with the physician or patient whenever necessary to attempt to avokl adverse health outcomes 
and consequent high cost events. Disease management includes: 

1) Identifying tiie dient organization and prospective program patient enrollees based at certain predetermined dis- 
ease states derived from research data. 
55 2) Utilizing medical claim, pharmacy claim, clinical data and laboratory data to assess disease states. 

3) Utilizing pre-defined interventions to manage the program. Examples of interventions could be mailing perkxlte 
notifications, mailing disease educational material, patient-initiated phone survey responses or even outbound call- 
ing performed by a staff of health care professionals. 
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4) Administering the process with case program managers who perform the necessary intervention with the dient 
(e.g. MCO. healthcare provider), doctor and patient. 

5) Recording interventions in patient care to determine if proactive disease management services improve specific 
disease outcomes. 

s 6) Processing intervention management information back through an analytic process to determine the outcome of 
intervention. 

10018] In the method of this invention, the case program manager (not shown in Figure 1 A. but whose functions are 
shown as part of the Case Management process 1 50 of Figure 1 B, which is desaibed in detail below) facilitates patient 

10 treatment by identifying to physicians patients who are likely to benefit from a change in tiierapy; and by suggesting 
therapies to the physk;ians; and by providing educational and freatment compliance assistance to patients (with ttie 
concurrence of the treating physicians). The case program manager does not diagnose disease or prescrit>e treatment 
regimens. Medical diagnosis and treatment is tiie sole responsibility of licensed physicians. 
[0019] By employing the process of the present invention, the case program manager identifies patients receiving 

IS therapy and, more importantiy, the subset of these who are not being treated in accordance with the preferred treatment 
regimen for the patient's disease state. This population of patients is very relevant to this invention; from this population, 
the treatment regimen of those patients who are not receiving the preferred therapy regimen can be automatically kien- 
tif led and influenced to change habits or conform to tfie recommended treatment regimen. 

[0020] For convenience, in the subsequent desaiption of the present invention, the case program manager is shown 
20 as a single source of external information such as ttiat from the Modeling Guidelines 1 04 for the Predictive Health Out- 
come Modeling process 102. and for the Intervention and Medical QukJellnes 105 for the process of Intervention of At- 
risk Patients 103. 

[0021] Generally, nwst functions of ttie case program manager are auton^ated and implemented by. for example, a 
dedicated computer system. However, end users may: provide extemal information as a disease management program 
25 is initiated. provkJe changed a new parameters to a disease management program based on experience, or modify 
intervention technk^ues as needed. 

[0022] For most embodiments of tiiis invention, the roles of the case program manager are divkJed artiong multiple 
persons or entities. For example, one "case management" entity can identify patients at risk for becoming "high-cost" 
patients, another entity can contact physicians with this information and with treatment advice as well as with patient 

30 educational materials and treatment compliance devices, and yet a ttiird entity can contact physicians directty. Still 
anottier entity can be responsible for managing the kientif ication of statistical Information and creation of predictive 
models. As a result of carrying out tiie method of the invention, a larger number of patients receive appropriate there- 

- pies tiian would otherwise, and. consequentiy, a smaller number of patients suffer from serious disease progression 
requiring extraordinary, and expensive, care. 

35 [0023] The method of the invention typfoally involves at least several treating physk:ians. One preferred entxxiiment 
includes approximately 100 treating physicians, but is also effective with larger numbers of physicians. e.g.. 250 to 500 
physicians, or more. 

The Disease Management System 

40 

[0024] A high level flowchart of the Disease Management System of the present invention is shown in Figure 1B. 
Referring to Figure 1 B, the Disease Management system includes a Disec^e Management Data Repository system 
101 which includes the Patient Data Collection and Integration process 110 and tiie Disease Management Database 
120. This is where the event-level information reskies. Next, the Disease Management system includes a Predictive 
45 Modeling process 130, a Risk Stratification process 140. an Intervention Management process 160, and an Intervention 
Records and Traddng process 1 70. 

[0025] A Case Management process 150 receives Intervention information from the Intervention Management proc- 
ess 160 and Results from the Intervention Recording and Tracking process 1 70. The Case Manager 150 provides exter- 
nally derived Information to the Predictive Modeling process 1 30 and Risk Stratification process 140. 

50 [0026] TTie Disease Management Data Repository system 101 includes a Patient Data Collection and Integration 
process 110 and a Disease Management Database 120. The Patient Data Collection and Integration process 110 
receives raw patient data from heaWicare sources, and processes the raw patient data to renxjve redundant information 
and format ttie raw patient data into a common, predetermined format. Initially, one or more sources of infomiation are 
required which allow for kJentif ication of an initial population of patients. 

55 [0027] Typical sources of raw patient data may include, for example, heatthcare provkJers such as doctors, hospitals, 
pharniades. otiier healthcare providers, and payers who pay for these servfoes which ail keep records for their patients. 
These records, however, may be scattered, difficult to access, have different formats, and contain duplicate or incorrect 
infonnation. Therefore, a more accessible source for such information exists in the health care claims records of a given 
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benef its provider. These health care claims records are used in one exenplary embodimerrt of the invention. 
[0028] The Patient Data Collection and Integration process 1 10 stores the formatted patient information in the Dis- 
ease Management Database 120, which Is the database storing the patient medical records, clinical data or other data 
used by the present invention. 

[0029] The Predictive Modeling process 1 30 of the present invention uses an identified disease, statistical restrictions, 
and a sample patient database to create a predictive model and rules which can identify patients, from a predetermined 
Identified disease patient population, who are at high risk to adverse health outcomes. As used herein, the term "iden- 
tified disease" refers to a particular disease about which the client may be concerned, such as asthma, depression or 
congestive heart failure (CHF). 

[0030] The Risk Stratification process 1 40 of Figure 1 B applies a statistical predictive model and rules to patient data 
from the Disease Management database 120 corresponding to a group of patients selected from the Disease Manage- 
ment database 120 based on a predetermined criteria. The predetennined criteria couW be "all dient (MCO) patients" 
or "all new employees" for example. The Risk Stratification process 1 40 identifies a subgroup of at-risk patients and cre- 
ates an intervention list from the subgroup. 

[0031] The Intervention Management process 160 schedules and performs interventions for each kJentified patient 
on the Intervention list such as sending letters or educatkxial materials, and making phone calls or home visits, to these 
at-risk patients. Finally, the Intervention Records and Tracking process 170 keeps a record of the interventions per- 
formed and their effects. 

[0032] The operation of tiie Disease Management System as illustrated in Figure 1 B is now described. 
[0033] Rrst, a particular disease of concern, as well as other predetermined restrictions, are Certified by the Case 
Management process 150. The identified disease and restrictions are supplied to the Predk:tive Modeling process 130. 
The Predictive Modeling process 1 30 receives a subgroup of patient medical data from the Disease Management Data- 
base 120 corresponding to patients having tiie identified disease and meeting other predetermined statistical criteria 
determined from research data. The Predctive Modeling process 130 ttien creates a predictive nrxxSel and rules from 
the subgroup of patient medical data which can identify patients from a predetermined identified disease patient popu- 
lation who are at-risk to adverse healtfi outcomes. 

[0034] The Risk Stratif ication process 1 40 receives the output predictive model and rules from the Predictive Modeling 
process 130, and further rules from tiie Case Management process 150. Based on ttie information provided by the 
Case Management process 150, medical and clinical information for a group of patients contained in tiie Disease Man- 
agement database 120 is retrieved, and tiie group of patients is the predetermined clients identified disease patient 
population. The Risk Stratification process 140 then uses the predtetive model and rules to Identify a high-risk subgroup 
of patients from the predetennined dlent's kJentified disease patient population who are at-risk of adverse health out- 
comes. 

[0035] identifying a high-risk subgroup is a subjective undertaking which is defined by the operator. It is not a Procru- 
stean bed. For example, "high-risk* can be determined based on the severity of tiie disease or condition. Or it can be 
driven by available resources: tiiere may be only so many resources available versus the cost of providing useful inter- 
ventions. A dassic example of "high-risk" is the ti-iage approach used in dealing witii major catastrophes: doni treat 
those who will die anyway, doni treat those who will live anyway; treat those for whom available intervention may result 
in sunrival or a lessening of permanent disability. Anottier exarriple is to define tiie high-risk subgroup as corrprising a 
certain percentage of the total group based on how many patients a particular operation can handle. So if tiie through- 
put of a particular system can only handle or manage Interventions in 1000 patients on a given day. then the 1000 
patients most in need out of ttie total population will be defined as the "high-risk" subgroup. In a similar way, tiie inter- 
venor may have only enough money to usefully intenvene in 1000 patients in six nx>nths. Hence by definition tiie 1000 
patients most at risk become ttie "high-risk" subgroup. Another example is one where dinical outcomes are ranked from 
1 to 5 in temis of possible useful outcome, and it is decided that Ihose with a possibility of a good outcome ranking of 
3 or greater shouki be progressed as ttie "high-risk" subgroup. In addition, age and age-related likelihood of an adverse 
outcome, or a positive outcome, may be used in defining a "high-risk" subgroup. For example It may be decided to 
define high-risk as tiiose who are female, past menopause, and have a family history of an estrogen-dependent dis- 
ease. And 2 or more of ttiese factors will usually be combined in creating tiie algorithm for kJentifying the "high-risk" sub- 
group. These are but a few examples of how one might define "high-risk". 

[0036] It shouki be noted also that aHhough this step is described in terms of kJentifying a single "high-risk" subgroup, 
graded levels of Intervention can also be defined and factored back into this analysis. So rather ttian d^lning a high-risk 
subgroup, one couW define a set of subgroups where each was accorded a particular risk factor, and ttien intervention 
carried out on a selected set of subgroups based on different levels of accessed risk. 

[0037] Once the high-risk subgroup; or a set of target subgroups, has been identified, the Risk Stratifk»tion process 
140 creates an intervention list ranking the patients according to a predetermined criteria Tbe intervention list is used 
by the Intervention Management process 160 of the present Invention to schedule and perform interventions, such as 
sending letters or educational materials, and making phone calls or home visits, to these high risk patients to prevent 
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and/or improve their likely health outcomes. 

[0038] The Irrtervention Management process 1 60 takes a data feed from the Disease Management Datat)ase 1 20. 
and the data is "client" identified disease patient data whfch is nomialized into the Disease Management Data Reposi- 
tory format. This data feed or detection process has parameters and rules received from the Case Management proc- 
5 ess 150 that Identify a specific patient meeting the conditions for participating in a disease program. This detection 
process provides a population for consideration in the specific identified disease program. 

[0039] The Intervention Management process 160 also passes intervention contact data back to the main Disease 
Management Database 1^ and the intervention list to the Case Management process 150. This interventwn contact 
data is used in the analytic process to. for example, determine the success of the particular form of intervention. 
10 [0040] The Intervention Record and Tracking system 1 70 keeps a record of the interventions and their effects, from 
which the Case Management process 150 can update external information used by the Predictive Modeling process 
130, as well as guidelines for interventions, and the Best Practice Guidelines to improve treatment regimens for an iden- 
tified disease. 

[0041] The following sections describe in detail each of the processes of the Disease Management system of tiie 
IS present invention, as illustrated by Figure 1 B. 

The Disease Management Data Repository and Data Integration 

[0042] The Disease Management Data Repository 101 is described witti reference to Rgure 2A, which is a high level 
20 flowchart illustrating the raw patient data acquisition, pre-processing, and database formation of the present invention. 
The Disease Management Data Repository 101 includes the Patient Data Collection and Integration process 1 1 0. Dis- 
ease Management Database 120. and a Research Database 250. 

[0043] The Patient Data Collection and Integration process 1 10 Includes Reimbursement Clainis sources 200 as a 
data source, a raw Patient Data Pre-processing process 210 to "clean-up" the raw patient data, a Conversion process 

25 220 for converting the raw data to a predetermined format, and an Update Patient Data process 230 to update patient 
infbnnation due to subsequent events or interventions (also called event-level infbntiation). 
[0044] In tfie Patient Data Collection and Integration process 110. Reimbursement Claims sources 200 provide raw 
patient data to the raw patient data pre-processing algorithm. The exemplary sources of infomiation. which allow for the 
identification of a population of patients who are cunently provided medical treatment are ttie clinicai records and the 

30 health care claims records of many healthcare benefit providers. As is known, claims for drug reimbursement, doctor 
visits, hospital stays, and laboratory tests are received and processed for payment/ireimbursement. In the exemplary 
embodiment of the present invention, this claims infbrmation is entered into, for example, a DB2 or Sybase database 
on a computer system (not shown). 

[0045J The present invention is not limited, however, to these Reimbursement Claims sources 200 as shown. In 
35 anotiier embodiment of ttie invention, data concerning individuals, such as demographic data; soaal data; personal 
data such as lifestyle, a history of sexual abuse or parental neglect or physical abuse, nutritional status; geographic 
data; family history; or other data can be used to populate the Disease Management Database. 
[0046] The method of the invention is typically earned out witii the assistance of an electronic database for storage, 
and retrieval, of data concerning an individual, such as mecfical data, demographic data, pharmaceutical data, diagno^ 
40 sis data and treatment data, from reimbursement claims sources 200. For example, the foltowing pharmaceutical data 
can be retrieved from reimbursement daims: 

a) patient identifier 

b) drug prescribed 
45 c) drug dosage 

d) amount of drug 

e) duration of drug therapy 

0 dates of recent prescription f ilisAefills 
g) provider identifier. 

50 

[0047] The data are stored preferably in machine-readable fbrm and are recoverable in discreet, searchable fields with 
a disaeet record for each patient. Each recad also preferably comprises a field for noting whether or not one or more 
case management interventions as desaibed herein have been undertaken. The data are stored in a computer and 
accessed through customized database utilization software. Such software provides searching and reporting (display, 
55 printing, and electronic distribution) capability. 

[0048] Rgure 2B is a high-level block diagram Illustrating three exemplary sources of infomiation suitable for use with 
the present Invention. As is illustrated in Rgure 2B, ttie claims infbrmation of such a provider wouW typically include 
three sources: pharmacy (Rx) claims 202, doctor (DR) claims 204 and hospital (HL) claims 206. As listed on the blocks 
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representing the claims information, many types of information would be available from the respective claims including 
drug codes, physician's names, diagnosis codes, procedures, various dates and other relevant information. Much of this 
information is referenced using codes, such as drug codes, procedure codes and illness codes. 
[0049] Continuing with Figure 2A. the Raw Patient Data Pre-processor 210 performs data integrity checks which iden- 
tify arxj process rejected or reconciled claims. 

[0050] To make the use of the database more eff teient the database utilization subalgorithm (not shown) of the Raw 
Patient Data Pre-processing algorithm 210 has the capability of eliminating redundant entries, of eliminating entries for 
patients who have become ineligit)le and of ignoring records for which a case management intervention has been 
undertaken within a preset period of time. 

[0051] Second, the Conversion algorithm 220 reads the source data files and populates the Disease Management 
Database 240 with the patient information in a predetermined database format. The Disease Management Database 
240 of the present invention uses Sybase, but any similar database product may be used. 

[0052] Finally, the Update Patient Data process 230 of Rgure 2A receives intervention management information from 
the Intervention Management process 160 and Intervention Recording and Tracking process 170 and updates tiie 
patient information of the Disease Management Database 120 to include information about interventions regarding the 
member patient. 

[0053] A more detailed flowchart of an exenplary embodiment of the Conversion process 220 is shown in Rgure 3. 
[0054] Referring to Figure 3. the File Manager 310 receives patient data ffles and identifies the incoming files, verifies 
that they are suitable for processing, and stores infbnnation about each file in a file inventory database. If the file is Hier- 
archical, the Rie Manager 310 sends the file to the Hierarchical Rle pre-processor to read the contents into flat files. 
The flat f Oes are then stored into tiie Disease Management Database 240 by tiie Rat file Processor 330 using the infbr- 
nation contained in the Input configuration table 340 and Output conf iguratk)n table 350. The patient data is then stored 
in tiie database using a Data Model. 

[0055] Figure 4 is an illustration of an exemplary Data Model as used in the patient data repository of an errbodment 
of the present invention. The Data Model includes a Source Data Inventory 410, which records aspects of incoming 
data during database population: an Exception Handling process 420 whk^h handles data exceptions during the popu- 
lation process; Client Tables 430. which contain lists of the Disease Management provkJer clients; and a Member Table 
440. which includes member specific identity information. 

[0056] The Data Model also includes, for each member patient in Member Table 440, a Claim Table 450. whk^h is a 
record of healthcare activity for a single member; a Laboratory Table 460. which represents the entities and relation- 
ships involved in gatiiering dinksal test data for a given member; and a Diagnosis and Procedure Table 470. whtoh con- 
tains a record of related diagnoses and medical procedures for a given claim. 

[0057] The organization process of the Data Model is as follows. Refemng to Rgure 4. ttie source Data Inventory 41 0 
records the progress and nature of incoming data during the database population process. The Exception Handling 420 
handles data exceptions during the population process. The 6»:eption may be caused by missing values, values out of 
range, or other errors In the data, and the Exception Handling 420 resolves these exceptions when they occur by tiirow- 
ing away the data, retaining some of the data, or resolving the errors based on available information. The Source Data 
Inventory 41 0 provides received client data to populate the database with Client Tables 430. 
[0058] The Client Tables 430 contain lists of tiie Disease Management provider clients which have patients and are 
subscribing to the system and method described in the invention. Each client in the Client Table 430 has patients 
defined as members in tiie Member Table 440. The Merrter Table 440 includes such information as member name, 
date of birth, and gender. 

[0059] For each menfiber patient in Member Table 440. a Claim Table 450 is kept. Each daim in Claim Table 450 is a 
record of healthcare activity for a single member. Data items recorded are. for exanple, dates when the claim was ini- 
tiated or resolved, drug and prescription information, details of a medical examination, the member's primary or other 
physidans, and encounter services or procedures provided. 

[0060] In addition, the Laboratory Table 460 represents the eotities and relationships involved In tiie requisition, 
accession, and resolution of laboratory tests performed for a given member. Data items recorded are, for example, 
blood tests, glucose tests, or ottier tests based on a single analyte. 

[0061] Finally, the Diagnosis and Procedure Table 470 records primary and one or more secondary diagnoses for a 
given daim, which are expressed as ICD-9-CM codes. Diagnoses can be grouped together into a Diagnosis-Related 
Group (DRG), and a DRG is one of 495 dassif ications of diagnoses in which patients demonstrate similar resource con- 
sumption and lengtti of stay patterns. The Diagnosis and Procedure Table 470 also records procedures corresponding 
to each diagnosis, and these procedures can be expressed as out-patient CPT codes, in-hospital HCPCS, or ottier pro- 
prietary codes. 

[0062] A second, identified disease specific database is created for tiie purposes of providing a database of identified 
disease patient data for the Predictive Modeling process 130. Returning to Rgure 2A. this database is the Research 
Database 250 which is a claims level database in a predetermined format, such as SAS format. Afthough Rgure 2A 



8 



EP 0 917 078 A1 



shows that the identified disease sample patient data used to populate the Research Database 250 is provided by the 
Disease Management Database 120. the present invention Is not so restricted and the Research Database 250 can be 
populated from Reimbursement Claims sources 200 using an appropriate pre-processing algorithm. 
[0063] Exemplary formats illustrating the research database format for each of the Rx, DR. and HL daims of the 
5 records contained in the research database are shown in Figure 5. As shown in Figure 5. claims are listed from claims 
1 to claim x and the appropriate information, for the particular service provider being claimed, is also presented. The 
DB2 database still represents a source of raw data elements which require processing by the raw patient data pre- 
processing algorithm 210. Subsequently, the data is routinely downloaded into a Research Database 250. 

10 Creation of Predictive Models 

[0064] Turning to the statistical prediction modeling, Rgure 6 is a high level flowchart illustrating the sample patient 
data exftraction process and predictive modeling process for an identified disease according to the present invention. As 
shown in Figure 6. the Predictive Modeling process 130 includes the steps of 1) Extracting Identified Disease Sanple 
IS Data 610; 2) Performing a Quality control operation (optional) 620; 3) Checking Whether the Data is Statistically Valid 
630; 4) Converting Claims level data into Event Level Data 640; 5) Processing the Event Level Files into Analysis Files 
650; and 6) Processing the Analysis File using Statistical Techniques to create an identified disease prediction model 
and rules. 

[0065] Refen'lng to Rgure 6, the process of determining a predictive model begins with step 61 0, Extracting Identified 

20 Disease Sample Data. The extraction process of step 610 receives the sample patient data from the Research Data- 
base 250 and an identified disease from the Case Management process 1 50 when the data has been converted to SAS 
format SAS procedures process the information to: 1) extract patients with the identified disease (step 610). 2) process 
the claims level information into event level information (step 640). 3) using predetermined variatsles and timeframe 
schemes, generate analysis files for analysis purposes (step 650) and 4) create a prediction model as a function of 

25 those variables most reflective of the correlation to an adverse health outcome (step 660). 

[0066] It should be mentioned that, from a statistical perspective, an important consideration in developing prediction 
models from datasets is sample size. To maximize the integrity of the prediction model, a valid sample size is an Impor- 
tant factor, and sample sizes required to determine prediction equations depend on the magnitude of association 
between variables. As these associations are unknown, all patients within any individual plan are initially included. 

30 [0067] The first step, extracting patients with an identified disease or condition (step 610). uses various parameters 
provided either by the case program manager, research source, or other healthcare professional to define which 
patients qualify for tiie overall initial universe of patients with the identified disease to be considered. 
[0068] For example, in one exemplary embodiment of tiie present invention, only patients having a corrtinuous enroll- 
ment witii the benefits provider of 12 morths or longer and having a daim for depression or treatment with anti-depres- 

36 sant medication are eligible. Of course, these criteria are exemplary and could be modified such that 24 nmnths or 6 
months of enrollment is satisfactory or that an indivMual must be 18 years of age. In the exemplary embodiment of the 
present invention, the Extracting of kjentified Disease Sample Data, step 610. extracts all claims data for patients with 
either an appropriate code for an identified disease (such as depression; see Appendix 1) or for treatment witii a drug 
used in treatment of the identified disease (for example, for depressfon, an antidepressant drug; see Appendix 111). 

40 [0069] It should be noted that in tiie healtii care industry various codes are used in claims information for indicating 
which procedures, treatmerrts, diagnoses, drugs, eto. are being claimed. For the exemplary embodiments of the 
present invention, examples of the selected codes are shown in Appendices I arxl II. These codes were found in Phy- 
sician's Current Procedural Terminology (CPT). American Medical Association (1995) and St Anthon/s ICD-9-CM 
Code Book (1994) which are both hereby incorporated by reference for their teaching of codes and sources of codes. 

45 As will be appreciated by ttiose skilled in the art any set of codes, representative of the various procedures, treatments, 
diagnosis, drugs, ete. relevant for use with the present invention would sufffoe. References to such codes occur 
throughout this specif k:ation. 

[0070] Subsequent to tiie extinction process of step 610 of Figure 6, tiie claim adjustment and integrity checks are 
optionally perfonned in ttie data Quality Control step 620. The Quality Control step 620 is optional, as. for exanple. the 

50 patient data for an identified disease may not require ttie step or ttie original Disease Management Database 120 m^ 
already be of sufficient quality due to ttie raw Patient Data Pre-processing step 210 (shown in Figure 2). 
[0071 ] One mettiod of Quality Control of step 620 generates, from the dataset defined above, intemiediate output files 
which contain sets of frequency counts for processing purposes. In one exemplary embodiment of the present inven- 
tion, witti depression as tiie identified disease, intermediate output files lor ttie following characteristics are generated 

55 for review: 

a. frequency counts of unique members by sex. age groups (0-9, 10-19...) and enrollment duration by montiis 
including: 
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i) Tables showing count of menrtoers by sex, ii) Table showing count of members within age groups, iil) Table of 
counts of age groups broken down by sex. iv) Table of enrollment duration by months I.e.. 1 nwnth to maximum 
number of months possible. 

5 b. frequency counts of ICD codes for depression (Appendix I), i.e.. number of members having at least one hit with 
each of the ICD codes in Appendix l-a any level ii) as first code. 

c. frequency counts of antinJepressant drugs (Appendix II): 

i) number of menders who have at least one claim for each of the drugs in Appendix III. 

10 

d. count of members who became eligible for processing due to ICD code only, by drug only, and by both ICD code 
and drug. 

e. frequency counts of numbers of all claims within each file (HU DR. Rx) by member. 

f. frequency counts of ICD codes (use only the first 3 digits of ICD codes) of any nature in DR (any position) and HL 
IS files - at least the top 10 with frequency of each. i.e., 2 tables one each lor DR and HL files. 

g. frequency counts of hospitalizations by calendar month. Counting calendar month backward from last month of 
eligibility or data availability. The last month for which data is available will be month 1 . the penultimate month with 
be month 2 etc. 

h. frequency counts of procedures related to depression (CPT codes, Appendix l-b). 

20 I frequency counts of all CPT codes (to the level of the first 3 code digits) - at least the top 10. 

[0072] The above frequency counts for use in performing preliminary evaluations as to the integrity of the data are 
exemplary and couU be modified to include/exclude parameters which are shown to be more/less useful. 
[0073] In another exemplary embodiment of the invention, with Congestive Heart Failure as the identified disease, the 
25 following frequency counts are generated: 

A) First, a frequency count of the number of enrollment periods for the members is generated. Then, for members 
with multiple enrollment periods of at least 6 nx>nths duration, it is determined if a CHF diagnosis is present in each 
enrollment period. Consequentiy, enrollment periods without a CHF cfiagnosis are excluded and, for members with 

30 multiple enrollment periods that have a CHF diagnosis, only the most recent enrollment period that contains a CHF 
diagnosis is kept. 

B) For the one enrollment period for all remaining members, all costs, denoted ALL COSTS, encountered by that 
member during the entire enrollment are identified. A complete proc univariate lor ALL COSTS is provided for each 
plan separately and all plans together. It should be noted that "proc univariate' is a SAS procedure whnh generates 

35 desaiptive statistics (e.g.. mean, standard deviation, etc.) 

C) From the ALL COSTS detemfiined above, costs which are specifically cardiovascular (CV), denoted CV COSTS, 
are identified. In doing so, a cost is considered to be a CV COST if a claim from the DR or HL file has any CV ICD- 
9 code in the first or second position. If a claim from tiTe Rx f ile is from therapeutic dass 04000 then it is counted 
as a CV daim and count cost as a CV cost. A complete proc univariate Ibr CV COSTS Is also provided Ibr each 

^ plan separately and alt plans together. 

D) From the CV COSTS, those costs which are specifically congestive heart failure related, denoted CHF COSTS 
are identified. A cost is considered to be CHF COST if a daim from the DR or HL file has any CHF lCD-9 code in 
the first or second position. A complete proc univariate for CHF COST is also provided for each plan separately and 
all plans together. 

45 E) For all member enrollment periods remaining, tiie total member nrK>nttis for each plan is calculated separately 
and together, in doing so, a member is considered enrolled during any month that they were enrolled for at least 
one day For this, a complete proc univariate is provkJed for member months fbr each plan separately and ail plans 
togetiier. 

F) Finally, a unique member count is provided fbr all patient status code =» 20 within the remaining enrollment peri- 
50 ods. It is noted that status code = 20 indicates that the patient has expired or dkl not recover. 

[0074] It should be noted tfiat. regarding ttie cost calculations, tiie following guidelines apply in ttie exemplary embod- 
iment of the present invention: 

55 a. the cost of inpatient hospitalizations, emergency services, physteian/oulpatient, and other medical services on a 
per daim basis are considered to be: 

AMTPAID + AMTCOPAY + Af^TRESERVE + AMTDEDUCT 
b. the cost of drugs are considered to be: 
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AMTPAID + AMTCOPAY 

where AMTPAID is the amount paid. AMTCOPAY is the amount co-payed. AMTRESERVE is the amount reserved 
and the AMTDEDUCT is the deductable amount. 

[0075] It should also be noted that, for purposes of a cost hierarchy, the following rules were used in the exemplary 
embodiment of the present Invention. 

1. Only hospitalizations for CHF can spawn other events. 

2. Hospital costs include all Rx. procedure, physician charges. 

3. Hospital visits can generate Rx and procedure events with costs set to zero (included in hospital cost). 

4. Hospital visits cannot generate separate doctor visit events. 

[0076] Once again, the above information, which is used to perform preliminary evaluations as to the integrity of the 
data, is exemplary and could be modified to Include/exclude parameters which are shown to be mae/less useful within 
the spirit of the present invention. 

[0077] With this Infonnation. a "quality check" is performed on the initial universe of identified disease patients to make 
sure that the final results. i.e., prediction model, is not unreasonably skewed due to invalid input infamation. This 
processing for maintaining data quality. Quality Control step 620. produces intermediate output files, and allows for a 
refinement of the extracted information by. for example, checking to see if an imbalance exists in the extracted informa- 
tion such as all dams are from indivkiuals over 60 years of age, all claims are from men» or other data int)alances 
which would othenvise taint the Integrity of a predlctk>n model. Step 620, in the exemplary embodiments, is performed 
manually by viewing the intermediate output files. It is contemplated, however, that using various threshold values, the 
frequency counts can be automatically scanned for a potential imbalance. 

[0078] Having now extracted and refined the claims level information according to varfous predetermined criteria 
deemed relevant for subsequent processing purposes, the intormatfon is converted into an event level format 
[0079] Returning to Figure 6, the next step Is the Convert Claims Level Data to Event Level step 640. To provkJe 
processing flexibility, particularly in assigning time windows for analysis, the above-mentioned second step (i.e.. con- 
verting the claims level information into event level information, step 640) is employed to generate two primary data files 
from which an analysis file can be created. 

[0080] In the exemplary embodiment of the present inventioa primary data file 1 1s a member level file and contains 
all data of a static nature (i e.. not time sensitive) such as 1) Member Key. 2) Date of birth. 3) Gender. 4) Rrst available 
date of enrollment (i.e.. start of dataset (1/1/92) or enrollment date). 5) End date of enrollment (i.e.. end of dataset or 
last date of enrollment), 6) Date of first identified disease event (for example, first prescription for antidepressant, or 
hospitalization for congestive heart failure). 7) Date of last hospitalization. 8) Number of records in events file (primary 
file 2). and 9) Mode of entry into the dataset (ag., i) Anti*depressant daig only, ii) Depression diagnosis only, ill) Both 
anti*depressant drug and depression diagnosis). 

[0081 ] Primary data file 2 is an event level file witti a record for each event ordered by member and the chronological 
date of the event, and. in the present invention, presented in descending order of event date. 
[0082] It should be noted ttiat an event, sometimes refen'ed to as an episode, is an occurrence whfch, based on din-, 
icai knowledge, is deemed relevant to the identified disease. Having knowledge of what raw data elements are available 
from tiie claims, a set of events is defined directiy or indirectly from the data elements where events can be based on 
an individual data element, a combinatfon of data elements or it can be derived from individual or multiple data ele- 
ments. 

[0083] Figure 7A is an exemplary list of events and format for primary file 2 (an event level fUe) for depressfon as the 
identified disease. As shown in Rgure 7A. the entries provided include: 

1 . Hospitalization for depressfon 

a. Any hospital claim klentified by hospital site code. 

b. Having a from and through duration of at least 1 day. 

c. Having ICD 9 code. 

d. Depression ICD 9 code occurring at any position. 

e. Illness indicator (Appendix V) 1 = major illness. 2 = suicide. 3 = major illness and suicide. 0 = everything else. 

2. Emergency room for depression 

a. Emergency room visit identified by emergency room site code. 

b. Having ICD 9 code (see Appendix l-a). 
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3. Doctor (non-hospital) visit for depression 

a. Any doctor claim. 

b. Having ICD 9 code (see Appendix l-a). 

c. Category: Psychiatrist =• 1 . all others = 0. 

4. Prescription for SSRI 

a. SSRI (seiective serotonin re-uptake inhibitors) therapeutic dass 5.51.3. 

b. Cost s 0 if generated from a hospital admission. 

c. Category indicator » blank 

5. Prescription for (Tricyclic antidepressants) TCA or (Monoamine Oxidase inhibitors ) MAOl 

a. Therapeutic classes 5.5.1.1 (tertiary amines), 5.5.1.2 (secondary amines), 5.5.1.4 (Monoamine Oxidase 
inhibitors). AND 5.5.2 

b. Cost s 0 if generated by a hospital adnrission 

c. Category indicator therapeutic class 1 = 5.5.1 .1 . 2 » 5.5.1.2, 3 a 5.5.1.4. 4 a 5.5.2 

6. Prescription for other neuroactive drug (From Rx file) 

7. Procedure for depressfon (from DR or HL files) 

Category: CPT codes or ICD procedure 

0 = Psychotherapy All CPT and ICD codes In Appendix l-b not listed befow. 
1 « Diagnostic 90801 , 90820. 90825, 90830. 
90862 

94,0x. 94.1X. 94.21,99.22, 
94.23 

2 = Shock therapy 890870. 90871 2 

94.24. 94.26. 94.27 



For this entry, costs are assigned to tfie doctor visit or hospitalization in which the procedure occurred. 

8. Hospitalization not for depression 

It should be noted that items under entry 8 coukj have been performed for a condition other than depressfon 
atthough these patients got into the cohort by virtue of receiving a depression diagnosis or receiving and antide- 
pressant at some time making it likely these procedures were fa depressfon. 

a. All hospitalization having from and through dates of at least one day duration. 

b. Major illness ICD 9 codes (see Appendix V). 

c. Category as in 1 above (1 = major. 2 = suicide. 3 = botti. 0 s all others) 

Counts for entries 9-1 3 are aggregated for each month. The date is that for tiie first occurrence of tiie Identified 
events. In the number field, the number of kJentified events occurring in that month are summed. 

9. Emergency room not for depression 

a. Emergency room visit identified by Emergency room 

10. Doctor (outpatient) visit not fbr depression 

a. Any doctor visit 

b. Excluding visit with a depression diagnosis (Appendix 1-a) i.e.. not in 3/above. 

1 1 . Prescription for possfoly related drugs 

Drugs identified in Appendix IV 

12. Presaiption fbr all other (non-depression) drugs 

All drugs not included in Appendices III or IV. 

13. Procedure not for depression (from Dr and HL files) 
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a. Category indicator 1 = major procedures, 2 = minor procedure (see Appendix IV). 

[0084] Rgure 7B illustrates the exemplary list of events and format for primary file 2 (an event level file) for the exem- 
plary embodiment with congestive heart failure as the identified disease. This embodiment exemplifies thjat the primary 
5 files 1 and 2 can be subdivided using the following exemplary ground rules which provide counts for the various events: 

I. Count as a hospitalization event, denoted HOSPITALIZATION, (using both 1st and 2nd ICD-9 codes) a claim hav- 
ing a from and through date of at least one day and having a site code of 04. It is noted that a site code distin- 
guishes between the sites at which the service under consideration took place (e.g.. emergency room, doctor's 

10 office, etc.). It should be noted that costs go to 1st ICO-9 code category only. Also, if a new hospitalization occurs 
within one day of discharge from a previous hospitalization, the two hospitalizations are bridged into one. If a new 
hospitalization occurs greater than one day following a previous hospitalization, the second hospitalization is con- 
sidered a new one. 

II. Count as an emergency room visit event denoted ER VISIT, (using both 1st and 2nd ICD-9 codes) a claim hav- 
15 ing a site code of 07. 08 or 10 OR a claim with the following the Hospital Conrvnon Procedure Coding System 

(HCPCS) codes: A0010-A0070. A0215-A0225. A0999 with a provider code » 81. It should be noted that costs go 
to 1 St ICD-9 code category only. 

III. Count as an office visit event, denoted OFFICE VISIT, (using only one ICD-9 code) a daim having a site code 
of 01 or 06 and having a unique date of service (DOS) but allow for different provider keys on the same DOS (if 

20 same provider key on same DOS. consider to be the same office visit) BUT if an office visit event occurs during a 
hospitalization, do not generate an office visit event (Attribute all costs for this event to the hospitalization). ALSO 
count as an OFFICE VISIT a daim witti the foltowing HCPCS codes: A0080-A0210 with provider code = 81 . For all 
other office visit events, costs go to 1 st ICD-9 code category only It should be noted that the following provider keys 
are not considered as separate office visits and shoukJ be bridged with an office visit that occurs on the same DOS 

25 if one exists: 1 ) 24 (therapeutic radiotogy), 2) 34. 35 (independent lab). 3) 55 (hosp o/pat lab x-ray). 

[0085] The three event types illustrated above are then further defined according to tiie associated Diagnoses. 
[0086] The next step of Figure 6 is the Processing of Event Level RIes into Analysis RIes. step 650. After generating 
the two primary files using the above described instructions corresponding to step 640. further processing using time- 
30 frame information and selected variables (independent and dependent variables) is performed on the event level data 
to generate an analysis file, at step 650. 

[0087] Figure 8 shows an exemplary format for the analysis file. As shown, the format of tfie analysis fie indudes a 
list of members in a first cdumn of a table. Across the top of the table is a list of variables, described in detail below. 
The body of the table provides Indications as to a member's relation to a listed variable. 
35 [0088] In particular, the processing from the primary files to the analysis ffles in step 660 indudes an algoritiim 
defined, in part, by a time window and a plurality of variables. The algorithm can be re-programmed tor various time win- 
dow adjustments as well as variable modifications. The analysis file generated at tills step is a member level file (i.e., 
organized with respect to members). The main analysis files are member level files derived from the information in ttie 
primary files. 

40 [0089] Each main analysis file is aeated to take Into account a single reference time window of censored events and 
prediction window of interest for that file. Each new time window applied to the data, in tiie exemplary entxxllment. 

requires another vnam analysis file. 

[0090] To generate ttie analysis file, a time window scheme, along with a plurality of variables, is applied to the event 
level data. 

45 [0091 ] Discussing the variables first, induded in ttie processing are both independent and dependent variables. The 
independent variables basically represent potential predictors of the adverse health outcomes; whereas, the dependent 

variables basically represent ttie adverse healtii outcome to be.predicted. 

[0092] To determine exemplary Independent variables for step 650. as many of the aiginal data elements as possible 
are used, assuming nothing about ttie kjentlfied disease. TTien. based on dink^al knowledge atx>ut ttie identified dis- 
50 ease, additional variables are created. Furttiermore. combinations of the data elements and/or variables, based on din- 
ical knowledge, are used as variables. Rnally. some variables may be created and used based on ttieir potential utility 
as a leverage point in disease management. 

[0093] In the exemplary embodiment of the present invention, ttie plurality of variables, in addition to each of ttie items 
in tiie event file, currentiy used by step 650 in the SAS routine for generating an analysis file for ttte exemplary embbd- 
55 iment witti Congestive Heart Failure (CHF) as the identified disease are shown betow in Table 1 . It is noted ttiat each of 
the events in Rgure 7B is automatically conskiered an independent variable for processing. 
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Additional Independent Variables of Interest: 




1. 


Age (at time of 1 st CHF diagnosis or drug therapy - one of the triple) 




2. 


Gender (M/F) 




3. 


HMO Membership (identification of particular HMO) 




4. 


Site of first CHF diagnosis (site code) 




5. 
6. 


Ischemic Heart disease (Y/N) 
Diabetes (Y/N) 




7. 


Adverse Lifestyle Diagnoses (Y/N) 




8. 


Cardiac Dysrhythmias (Y/N) 




9. 


Other Heart Disease (Y/N) 




10. 


Hypertensive Disease (Y/N) 




11. 


Number of Co-Moftid diseases (0-x) 




12. 


Number of ACE inhibita prescriptions (0-x) 




13. 


Number of digoxin prescriptions (0-x) 




14. 


Number of loop diuretic prescrptions (0-x) 




15. 


Number of other CV prescriptions (O-x) 




16. 


Number of non-V presaiptions (0-x) 




17. 


Medication Possession Ratio (Compliance measure) 




18. 


Number of CHF hospitalizations 




19. 


Number of CHF emergency services 




20. 


Number of physician office visits 


21. 


Total Costs 






In-Patient Hospital Costs 






Emergency Room Costs 






Doctor Costs 






Pharmacy Costs 


22. 


Cardiovascular Costs 






In-Patient Hospital Costs 






Emergency Room Costs 






Doctor Costs 






Pharmacy Costs 


23. 


CHF Costs 






In-Patient Hospital Costs 






Emergency Room Ck)sts 






Doctor Costs 



[0094] Turning to the dependent variables, potential dependent variables, for example, contemplated for use with the 
present invention are results to be predicted. For CHF. such predicted results include: 
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1 . Hospitalization (HL) for CHF This is a dichotomous variable which is referred to as the HL irxJicator such that HL 
s 1 if an admission occurred, otherwise the indicator equals 0. 

2. High Cost. For example, the High Cost indicator may be defined as the highest 10% of resource utilization meas- 
ured in dollars. Resources counted from time of cost in the top 10% of the first CHF diagnosis or receipt of first 

5 CHF-related drug (in the record) + 1 . 3 and 6 months • separate analyses for each time period. Again, this is a 
dichotomous variable referred to as the High Cost indicator such that if the patient, for exarrple, is In the top 10%. 
High Cost = 1 , othenwse High Cost = 0. 

The High Cost indicator, in the exemplary entxxjiment, could also be defined as the distribution of total cost 
per member (PMPM) in the prediction region (B to C). The High Cost indicator is set to 1 for the 10% of members 

10 with the highest PMPM in the Total Cost distribution and set to 0 for all others. 

3. Death. 

[0095] Although only three dependent variables for the given exanrple are listed above, as ttx)se of ordinary skill in 
the art will appreciate, other known or yet unknown variables consistent with the goals of the present invention may also 
IS suitably serve as a dependent variable within the scope of the present invention. 

[0096] Turning to the time window aspect of the generation of the analysis file, rt should be noted that there is one 
analysis record for each selected member. 

[0097] In the present invention, a scheme, as described below, has been developed for defining prediction zones and 
censoring data to create the analysis file. That is, refening to Figure 9, a time window basically defines a prediction zone 
20 or region 910 and an events window (analysis region) 912 from where activity is used to predtet something in the pre- 
diction zone. As those skilled in the art will appreciate, additional time window schemes may also adequately serve the 
present invention. 

[0098] For purposes of explanation, the time that the claims history covers is referred to as the time window tiiat starts 
at some point 'A' and ends at point 'C*. The time interval is divided into analysis and prediction regions by point *B' such 
25 that A<B^a That is to say. B* represents the present 'A* represents the farthest past event and represents the far- 
thest future event 

[0099] By way of example. Jane Doe's analysis record is based on claims from 1/1/91 through 6/30/93. Therefore, 
A=1/1/91, C=6/30/93 and B can be selected somewhere in between, such as 12/31/92. Generally. A is defined based 
on the data extraction protocol (i.e. . from when the data is available) and C is defined by the last day fbr which the mem- 
30 ber is still enrolled and eligible for the benefits. Of course, variations of those general points of definition could be 
selected within the scope of the present invention. 

[0100] The definition of tiie present instant B is important. In the subject invention, two basic definitions of B were 
devised in order to maximize the accuracy of ttie predk:tion model. Alttiough. as would be understood t>y those skilled 
in the art, alternative definitions of B may also be used. 
35 [0101] Figure 10A illustrates an exemplary time window scheme, referred to as Scheme 1. for use in processing the 
data from the event level files shown in Figure 6. 

[0102] In Scheme 1 , the event prediction region is set from B to C such ttiat B=C-{x# of months) for all the members 
in the analysis. For example, if a 6-month CHF hospitalization (HL) model (i e, HL is used as a dependent variable) is 
to be built then B=C-(6 months) . In Jane Doe's example. B wouM equal 12/31/92. Therefore, only data covering from 
40 A through B (1/1/91 -12/31/92) is used to predict the CHF in the 'next 6 months'. The phrase 'next 6 months' in ttiis con- 
text implies tfiat the time point B Is "NOW" and any time after it is in the FUTURE and any time before it is in the PAST. 
This is a key concept of Scheme 1 and is Inrportant to understanding tiie predctfon model implementation and applica- 
tion. 

[0103] In alternative embodiments, analysis weights which reflect proximity to the event to be predicted can be used. 
45 for example, within 3 montiis x 1 , 3-6 months x .75, 6-9 months x. .5.9-1 2 months x .25. greater than 1 2 months x . 1 25, 
Other suitable weighting technques, as wilt be appredated by those skilled in the art such as negative weights couki 
also be used. For example, in the exemplary embodiment of the present invention, the actual weighting factor used is 
l/e** where x = time in months from point B for each event. 

[0104] Therefore, given a selected time window scheme and an appropriate set of predetermined variables, the 

50 processing step of 650 generates the analysis file. 

[0105] Returning to Rgure 6. once the Analysis files are generated in step 650. the next step, step 660. is to Process 
Analysis RIe Using Statistical Data, step 660. which provides the Identified Disease Predictfon Model. 
[01 06] Using the analysis file, tiie model fbr kf entif lcation/k>rediction can then be developed in various ways using sta- 
tistical techniques. In particular, the analysis file, now at a member level, is processed using statistfoal functions avail- 

55 able in SAS. In the exemplary embodiment of tiie present invention, tiie statistical processing performed to generate the 
predictfon model is multiple logistic regression. As will be appredated by those skilled in tiie art. ottier statistical tech- 
niques may also be suitable for use wrtii the present Invention. 

[0107] In tiie exemplary embodiment, the statistical processing, when applied to the analysis file, kientifies variables 
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which meet predetermined levels of significance (e.g.. probability value < 0.05). These variables then form a prediction 
model which is a mathematical equation of the following form: 

Logit(p) aa-i-bx^ +0x2...+ ZX| 

where x1...xi are the identified variables and a...z are there parameter estimates. An individual's probability (p) 
for the outcome under consideration is tiien determined using the following formula: 

p = e-'^'*<^V(Ue'*^*>). 

[01 08] Using tiie above steps* several experiments were conducted. In one experiment, the results for a model based 
on Scheme 1 with all commercial members and using the HL indicator as a dependent variable were determined. The 
resulting independent variables, most likely to predict an adverse CHF health outcome, were 1) hospitalization for CHF. 

2) loop diuretics - days supply 3) hospitalization for hypertension -length of stay, 4) doctor visits tor CHF, 5) doctor visits 
for Ml, and 6) ACE inhibitor possession (negative indicator). 

[0109] In another experiment, the results for a nxxiel based on Scheme 1 with all commercial members with no prior 
CHF hospitalization and using the HL indicator as a dependent variable were determined. The resulting independent 
variables, most likely to predict an adverse health outcome, were 1) loop diuretics - days supply, 2) doctor visit for CHF, 

3) hospitalization for IHD, 4) doctor visit for IHD. 5) emergency room visit for diabetes. 6) hospitalization for hypertensfon 
■ length of stay. 7) emergency room visit for lifestyie, 8) hospitalization for other heart diseases. 9) doctor visit for pul- 
monary conditions, 10) doctor visit for anemia/emergency room visit for anemia, and 1 1) prescription (Rx) for "other" 
CV drugs. 

[01 1 0] In still anotiier experiment, the results for a model based on Scheme 1 with Medicaid meni)ers and using the 
HL indicator as a dependent variable were determined. The resulting independent variables, most likely to predict an 
adverse health outcome, were 1) hospitalization for CHF. 2) loop diuretics - days supply, 3) doctor visits for CHF. and 4) 
emergency room visit for diabetes. 

[0111] An alternative to Scheme 1. and referred to as Scheme 2, is illustrated in Rgure 10B whrch shows a second 
exemplary time window scheme for use in processing the data from the event level files generated in the present inven- 
tion. 

[0112] A difference between Scheme 1 and Scheme 2 Is the definition of the prediction region for members which 
have at least one identified disease hospitalization or emergency room visit (HL/ER). The prediction region starting at 
point B, in Scheme 2, is defined in multiple passes over each member's record. Turning again to Jane Doe's analysis 
record (from 1/1/91 tiirough 6/30/93, A=1/1/91. C=6/30/93) to illustrate how this aspect works fa defining point B, 
assume that Jane Doe was hospitalized for depression three times: on 4/1/91 . 4/1/92, and 4/1/93. 
[01 1 3] Point B is set equal to the date of the first identified disease HL/ER - 1 month or set equal to point C if a mender 
never had the identified disease HL/ER in their claims Wstory. For Jane Doe. B=4/1/91. In tiie exemplary errtxxfiment 
of the present invention, moving back one month from the HL date is performed to simulate tiie nrxxJei application envi- 
ronment. There would probably be at least 30-day lag from model scoring to ttie disease management actions based 
on tiie scoring reports. Thus, in Jane Doe's record B»4/1/91-(1 montii)n>2/28/91. Jane's record, in tttts case. woukJ not 
be used in the model building because the time span of the analysis region is only two months-less than the exerr^ary 
six montii data history requirement. 

[01 14] Repeating steps 1 and 2 using second (or third or...) HL date to set point B. Jane Doe*s recond would eventually 
make it into nxxiei building on the second and third pass. This process, in the exemplary enrtxxliment terminates after 
three or four passes since there wouM probably be very few members witti five or more identified disease HUERs in 
the study populatfon. 

[01 1 5] It should be noted that the consequence of repeated modeling Introduces added conplexity of setting up addi- 
tional independent variables. An important advantage, however, of Scheme 2 i& that tiie prediction HUER rate wouM 
likely be higher tiian in Scheme 1. 

[01 1 6] In still anottier alternative embodiment, analysis weights which reflect proximity to ttie event to be predated 
can be used, for example, within 3 monttis x 1. 3-6 morths x .75. 6-9 montiis x. .5, 9-12 morths x .25, greater ttian 12 
months x .125. Ottier suitable weighting techniques, as will be appreciated by ttiose skilled iri the art. could be used. 
These type of weghting techniques may be used with either Scheme 1 or Scheme 2. 

[01 17] It shoukj be noted that each of the experimental results indicate a different number of independent variables 
are used for tiie specific predction models; and. depending on ttie precision of ttie models desired, more or fewer inde- 
pendent variables m^ be used based on their individual ability to accurately predict the selected dependent variabla 
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Risk Stratification and Generation of Intervention Lists 

[01181 Next, the determined prediction model is applied to the client specified data. The determined model can be 
applied to the existing data, to the data as it is regularly updated or to other claims databases for other benefits provid- 
ers. To do so. only the determined Independent variables of interest need to be processed. Of course, as new claims 
databases are to be analyzed, the entire process can be repeated to generate a new model in order to determine if 
other variat)les may be better predictors. 

[01 1 9] The output generated by applying the model is a file containing a list of alt of the patients having the identified 
disease ordered by an indicator representative of the likelihood that that patient will have an adverse health outcome 
(i.e., experience that is defined by the dependent variable). This list can then be divided, for example, into subgroups 
such as in S% or 1 0% inaements of patients 111^ to have the adverse health outcome. 

[0120] Model performance can now be assessed by determining the number of actual adverse health outcomes 
occurring in the prediction window for each 5% or 10% subgroup. 

(0121 J Applying the model to future claims data or other databases of identified disease patients or building a new 
model in a new database as described above, patients with an identified disease at high risk can be identified allowing 
for various types of intervention to maximize the effective alfocation of health care resources for these patients. The 
Risk Stratification (RS) process 140 is required to generate such lists of patients, and the Inten^ention Management 
process 160 receives these lists and initiates interventions with the patients with the identified disease. These proc- 
esses are described in more detail below. Such interventions may take the form of 1) specific case management, 2) 
novel interventions based on subgroup characteristics. 3) high risk intervention, 4) high (relative) cost interventfon. or 
5) plan modification all ac^ering. of course, to the best practice guidelines. 

[0122] Referring to Figure 1B. the Risk Stratiftoation (RS) process 140 is required to support the Disease Manage- 
ment system by providing the Intervention Management process 1 60 witti a list of patients who are at-risk of an adverse 
health outcome for an Identified disease. This list of patients is called the Intervention List. 

[0123] Figure 1 1 shows a high level flowchart showing the Risk Stratificatfon process 140 including a RS Front End 
(FE) 1 1 10 module, a RS Mining Engine (ME) 1112 module, and a RS Database 1118. These two modules collaborate 
to produce Intervention lists from the RS Database 1118. 

[0124] The RS Front End (FE) 1110 allows end users to enter all of the information necessary to maintain and run 
disease programs for clients. 

[0125] The RS FE 1 1 10 of the present invention is written using Delphi 2.0. which is a 32 bit software development 
tod. The RS FE 1 1 10 stores client and disease parameters in Sybase System 1 1 runrtng on a Windows NT or UNIX 
based server. The RS FE 1 1 10 uses the Bortand 32 Bit Sybase SQL Unks database drivers. However. It is contem- 
plated that the present invention can be practiced using any similar development and database toots and is not limited 
to tills configuration. 

[0126] The RS Mining Engine (ME) 1112 runs the scheduled client identified disease programs yiekfing intervention 
lists that are provided to the Intervention Management process 160 of Rgure IB. The RS ME 1 1 12 is a batch/daemon 
process and follows this bask: program logic: 

A. Run nightiy (batch) or as a daemon process 

B. Determine what client klentif ied disease programs need to run based on schedule and available data 

C. For every scheduled client disease program: 

a) Get cfisease program rule components. 

b) Get disease program parameters for each rule component 

c) Validate that the necessary data streams (R^. M^ and Lab) exist for the Klentif ied disease program 

d) Initialize the scheduled client identified disease program 

e) Execute the scheduled client Identified disease program 

f) Provkle inten^ention lists to the Inten^ention Management process 160 

D. Terminate (batch) or set process to sleep (daemon) 

[01 27] The RS ME 1 1 1 2 is written using Delphi 2.0. which Is a 32 bit software devetopment tod. The RS ME 1 11 2 
processes disease parameters provided by the RS FE 1 1 10 combined with client pharmacy claims, medwal claims and 
laboratory test information for specific disease programs producing specif k; inten^ention lists all of whfch are retrieved 
from or stored in a relational database. The RS ME 1 1 12 utilizes the Sybase System 1 1 database running on a Win- 
dows NT or UNIX based server. The RS ME uses the Bortand 32 Bit Sybase SQL Unks database drivers. However, it 
is contemplated that the present invention can be practiced using any similar development and database tools and is 
not limited to this configuration. 
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101 28J The operation of the Risk Stratification process of Figure 1 1 is now desaibed. End users, which may either be 
coupled to the Case Management process 150 of Figure 1 B or another separate entity, provide end user identified dis- 
ease program information to the RS FE 1 1 1 0. The RS FE records infonftiation fbr the setup of new identified diseases, 
new disease programs, predictive models and rules, client specific parameters, disease specific rule parameters, and 
5 new clients; and the RS FE 1 1 10 associates disease programs with clients, schedules disease programs, and runs 
informational reports. The RS FE 1 1 10 records this information as a ''disease program* in a fbrmat fbr use by the RS 
ME 1112. 

[0129] The disease program Is provided by the RS FE 1 1 10 to the RS database 1 1 18. and the RS database 1118 
also receives predictive nx)del and rule information from the Predictive Modeling process 130. Finally, the Disease Man- 
10 agement database 120 provides patient medical information to the RS database 1 1 18 fbr the RS ME 1 1 12 when the 
RS ME 1 1 1 2 applies the predictive model to the patient data Rnally. the RS ME 1 11 2 receives the information con- 
tained in the RS Database 1 118 as the RS ME executes the disease program data and applies the predictive model to 
the patient data. 

[0130] Figure 1 2 is a high level flowchart showing the RS ME 1 1 1 2 of the Risk Stratification process of the present 
IS invention. The RS ME 1 1 12. as shown in Figure 12, is composed of three major sub-systems: a RS Schedule Manager 
(SM) 1210. a RS Rule Manager (RM) 1214 and a RS Intervention List Manager (ILM) 1216. Each of the three sub-sys- 
tems interacts with the RS Database 1118. which can be a subset of tiie Disease Management database 1 20 of Figure 
1 B. containing dient and identified disease program analytic configurations. 

[0131] The Disease Management database 120 is regularly updated with patient information (Member. Eligibility, 

20 Pharmacy (R^) Claims, Medical (MJ Claims and Qinical Laboratory (Lab) Claims) for each client. Consequentiy. tine 
RS Database 1 1 18 is also updated regularly with client and client menft)er Infbrmation. The RS ME 1 1 12 gathers rele- 
vant client patient information from the Disease Management Database 120 to be processed by the disease program 
analytic rules. In the exemplary embodiment of the invention, all relational databases are SYBASE System 1 1 . 
[0132] The RS SM 1210 compiles a list of identified disease programs to execute by examining each enrolled dient 

25 to see if the schedule time has arrived for the program to execute. Additionally, dient disease programs must be 
approved for execution by the RS ME 1 1 1 2 befbre they wsv be scheduled. Approval indicates that all client disease pro- 
gram parameters are entered and that the data entered has been validated by the RS FE 1 1 10 and is ready to be proc- 
essed in the RS ME 1 1 12. Rnally. the RS SM 1210 verifies that all required data streams are available. The RS ME 
1112 may be a batch program that is executed periodically. For each identified disease program which is selected by 

30 the above logic, an RS RM ot^'ect is aeated. RS RM objects are executed sequentially. 

[0133] The RS RM 1216 then assembles the rules required to Implement the specific identified disease program into 
an ordered sequence. These rules are described in detail subsequently, and are provided by the Predictive Modeling 
process 130 and the Case Manager 150. Each rule object is initialized with disease program and dient specific rule 
arguments. Rules sequences desiratsly contain one or nfx>re Common rules and one or nrx>re sequence of rules called 

35 Patient Group Classifiers (PGCs). PGCs are used to stratify a targeted dient patient population into specific groups for 
Intervention or reporting based on specific criteria. All interventions and reporting is performed based on patient mem- 
bership in one or more of the disease program PGCs. 

[01 34] Common rules are executed in the specified order prior to any PGCs. In general, rules are designated as com- 
mon rules because they either prepare the environment fbr other rules (Qient Partidpation. R, Claims, M, Claims, etc.) 
40 or they perform exdusions that reduce the overall patient set size prior to being acted upon by other conplex rules 
(Patient Active. Patient Age. Patient Gender, etc.), thus irrproving overall perlbrmance. Patients who fair the specified 
rules are removed from the patient set. 

[0135] PGCs are executed in parallel witii the rules in each PGC also being executed in parallel on the patient set 
provided by the common rules. PGC rules use a tally mechanism fbr each patient in the set to indicate passage or fail- 

45 ure of tile specified rule fbr ttiat patient. 

[0136] Upon completion of all PGCs the RS ILM 1216 scores each patient fbr membership in each PGC. The RS ILM 
1216 then generates and stores intervention lists for later processing by the Intervention Management process 160. 
[0137] The RS SM 1210 initially queries tiie RS Database 1 1 18 at startup of batch process or periodically if running 
as a daemon to determine if the approved dient identified disease programs scheduled run date has arrived and if all 

so required dient data streams are up to date. If all required data streams are available, a Rule Manager (RM) object is 
aeated for each client disease program. 

[0138] identified disease program attributes are stored in a table. One attribute is the approval status. Each identified 
. disease program is desirably approved before it is scheduled. If any identified disease programs are scheduled, then 
the disease program approval may not be revoked. 
55 [0139] Determining which programs require execution and when is accomplished via a schedule table which contains, 
among ottier things, a status and a scheduled run date. Once the scheduled date is reached the program is executed 
and the status is updated to running. 

[0140] The RS RM 1214 is responsible for running and managing the results of a single disease program. 
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[0141 ] The rules are grouped according the Patient Group Classifier (PGC) that they are assigned ta Rrst all the com- 
mon rules (those without a PGC) are run. Then the rules for each PGC which exists in the disease program are run 
[0142] The RS ILM 1216 evaluates each client disease program that successfully executed and corrpiles a listing In 
a intervention candidates table of the members selected by the program as belonging to each PGC within that program. 
[0143] A member is included in a PGC if the member has not been deleted from the set by any convnon rule, and the 
member's output for each PGC rule matches the desired value (1 for non-negated ailes and null for negated rules). 
[0144] Members who are included in a PGC are populated into an interventions table, which can also be the interven- 
tion list. This table includes identifying information for the member selected, the program run, the PGC in which the 
member was included/and the physician which was Identified if the Physician Identification Rule was used. 

Rules - General Classification 

[0145] A rule classified as a "Root Rule" indicates that the rule is required to run before all others and performs certain 
environment initializations for all other rules. Every Identified disease program must have one and only one root rule. 
Cun'ently. the only root rule is Client Participation. 

[0146] A rule classified as a "Common Rule" indicates that the rule is eligible to be executed prior to any PGC. Mem- 
bers who 'fair common rules are removed from the patient set. A rule can be simultaneously eligible to be executed as 
a common rule and a PGC rule. 

[0147] A rule classified as a "PGC Rule" indicates that the rule is eligible to be executed after common rules in parallel. 
Members who 'pass' PGC rules are marked in a column specifically added for that rule in a table. A rule can be sinxjl- 
taneously eligible to be executed as a common rule and a PGC rule. 

[0148] The rule "Creates Pharmacy Claims" creates a table for pharmacy claims. Every Identified disease program 
that uses pharmacy claims for a data source desirably has a rule that performs this function prior to rules that use phar- 
macy claims. 

[0149] The rule "Creates Medical Claims" creates a table for medical claims. Every identified disease program that 

uses medical claims desirably has a rule that performs this function prior to odes that use medical claims. 

[0150] The rule "Creates Clinical Test Data" creates a fable for clinical test data. Every disease program that uses 

laboratory claims desirably has a rule that performs this function prior to ailes that use laboratory claims. 

[01 51 ] The rule "Uses Specialties" uses physician specialty infomiation. 

[01 52] The rule "Uses Pharmacy Qaims" uses the table containing pharmacy claims infonnation. 

[0153] The rule "Uses Medical Claims" uses the table containing medical claims information. 

[01 54] The rule "Uses Clinical Test Data" uses the table containing clinical test information. 

[0155] All the rule objects in the RS ME 1 1 12 are descended from a common ancestor which provides some basic 

functional structure shared by all rules 

Rules Selection Rules and Intervention Rules 

[0156] The present en^odiment of the RS ME 1 1 12 supports various selection and intervention rules: 

1) Client Participation Rule 

Identifies whether a patient is part of a group that has been enrolled into the disease management program. 
This rule will ensure that all patients considered by ttie following rules are part of a group that tiie client wishes to 
have participate in ttie program. This rule may also validate that the patient has the proper benefit structure to per- 
mit ttie disease program to function. Client Participation is currentiy the only root rule. It is desirably, tiierefore. ttie 
first njle in every disease program, it is always executed as a common mla 

2) Rx Claim Rule 

This rule selects all pharmacy claims data that is applicable to tiie execution of a single identified disease pro- 
gram. It identifies all pharmacy presaiption claims selected for a specific drug group wittiin a specified analytic time 
frame. The R^ Claim rule is always a comnrwn rule. It is typically only run once in a given program. 

3) Existence of a Specific Drug Rule 

This rule identifies menrtf^ers with at least one claim for a drug in the specified drug group within the rule time 
frame. This rule may be run as either a common or a PGC rule. 

4) Recurrent Patient Rule 

This rule identifies whettier a patient has a pattern of drug use which indicates the potential of muHlpie inde- 
pendent episodes (recurrence) of a disease. The rule will select patients with at least a certain number of disaete 
episodes of a particular drug therapy. This rule may be run as either a comnron or a PGC rule. 

5) Stoppage in Current Therapy Rule 

This rule identifies patients whose drug therapy for a particular drug group has been stopped. This is deter- 
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mined based on the last prescription for a drug in that drug group. This rule may be run as either a common or a 
PCG rule. 

6) Patient Age Rule 

This rule identifies patients whose ages tell within a specified target range. This rule may be run as either a 
common or a PGC rule. 

7) Minimum Patient Eligibility Rule 

This rule identifies whether a patient is eligible for medical and/or drug benefits for a spectfied continuous 
period of time. This rule may be run as either a common or a PGC rule. 

8) Patient Active Rule 

This rule verifies that a member is active and in a group which is included in the program at the time of inter- 
vention. This rule may be run as either a comnrton or a PGC rule. 

9) Average Puff Equivalence Rule 

This rule identifies whether a member has the required average puff equivalence of drug therapy during a 
specified time frame. This rule may be run as either a common or a PGC rule. 

10) Count of Occurrences Rule 

This rule identifies whether a patient has a selected range of occurrences on different filled dates fbr a speci- 
fied drug therapy This rule may be run as either a common or a PGC rule. 

11) Patient Gender Rule 

This rule identifies members of a particular gender. This rule may be mn as either a comnx)n or a PGC rule. 

12) Dose Level Recurrence Rule 

This rule identifies whether a patient has a pattern of drug use within a specified dose range which indicates 
the potential of multiple independent episodes (recurrence) of the disease at the same or similar severity. This rule 
may be run as either a common or a PGC rule. 

13) Continuous Therapy at Required Dose Level Rule 

This rules identifies patients who have continuous drug therapy within a specific dose range for a specified 
length of time. This rule may be run as either a conrvnon or a PGC rule. 

14) Concurrent Therapy Rule 

This rule identifies patients who have overlapping therapy of at least a given duration for the spectfied drug 
groups. This rule may be run as either a common or a PGC rule. 

15) Dose Level Rule 

This rule identifies patients who have Rx Claims fbr a specified dmg therapy witiiin a specified dose level range. 
This rule may be run as either a common or a PGC rula 

16) Drug Usage Level Rule 

This rule Identifies members whose drug usage relative to expected values is within a specified range. Typi- 
cally, this rule will be used to determine members who are non-compliant with a specified drug therapy. This rule 
may be run as either a common or a PGC rule. 

17) Weighted Existence of Specific Drug Rule 

This rule identifies members whose drug therapies fall witiiin a designated risk score range. Each drug therapy 
is assigned a risk score and a member's drug history is assessed to determine his/her accumulated risk score. This 
rule may be run as either a common or a PGC rule. 

18) Physician Identifk^tion Rule 

This rule selects the specific Prescriber to send communication regarding a men*er who has been identified 
fbr intervention. This selection is based on ttie Pharmacy Claim data fbr that member and/or information about the 
member's primary care physician which may be found in the Member data in the Patient Data Repository 120. This 
rule may be run as either a common or a PGC rule. 

19) All Member Rule 

The All Member Rule selects all members present in the record set. This is used to support a PGC which con- 
tains all members selected by tfie common rules. This rule may also be used internally by the RS ME 1 1 12 in ader 
to support certain types of disease program optimization. This rule may only be used as a PGC rule. 

[01 57] Appendix VI includes a list and descr^jtion of the selection rules as used in one embodiment of tiie invention. 
It should be apparent to tiiose skilled in the art that these rules can be modified or deleted, and new rules created Ibr a 
particular embodiment of ttie invention. 

Intervention Management Process 

[0158] Once again referring to Figure 1 B, the Risk Stratification process 140 outputs the Intervention List to tfie Inter- 
vention Management process 160 to initiate specific interventions. Interventions may include initial offerings, fully 
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administered disease programs, forwarding educational materials, inbound or outbound telecommunications, faxes, 
Email or Voice Response interactions with member patients identified on the Intervention list. The Intervention Manage- 
ment process 160 provides the intervention information to the Intervention Records and Tracking process 170, which 
records the interventions to determine if proactive disease management services Improve specific disease outcomes. 

5 [0159] Figure 13 is a Ngh level diagram of the Intervention Management process 160 of tiie present invention, and 
the intervention process, called an inten/ention program, is performed on an intervention list of client members having 
an identified disease. The Intervention Management process 160 shown in Rgure 13 includes Program Initiation 1310, 
which starts the Intervention program; Enrollment 1320. which enrolls Identified patients into ttie Intervention program; 
intervention 1330, which Initiates the intervention with the enrolled patient; and Analysis 1340, which analyzes the 

10 results of an Intervention with a patient. 

[0160] The Intervention Management process 160 is provided data by tiie Disease Management database 120 as 
well as the intervention list from the Risk Stratification process 140. This data feed or detection process has parameters 
that identify a specific patient meeting tiie conditions for partidpating In a disease program. This detection process pro* 
vkJes a population fbr consideration in the specific disease program under tiie following conditions: 

IS 

1) The Disease Management database 120 provides client's updated identified disease patient data to the inter- 
vention management system on a scheduled basis. 

2) The Intervention Recording and Tracking process 170 passes intervention contact data back to the Disease 
Management database 1 20. This intervention data is stored tiiere fbr use in the analytic process. 

20 3) The lnterventk>n Management process 1 60 detects, selects and passes new inten^ention data on "adds" which 
are defined as new enrollees, changes in disease detection, subsequent diagnosis or an indivKlual enrollment 
request from an Intervention manager. 

4) The Intervention Recording and Tracking Process 170 re/ises patient data on those indivKluals previouisiy 
selected for the program. Data revisions occur when personal or medical data changes. For example, additional 
25 medical or pharmacy daims are received or additional laboratory reports are secured. 

[0161] Referring to Rgure 13, the first step of the process Is program Initiation, step 1310. Program Initiation tea proc- 
ess where a disease program Is initiated through the process of selection of a population of patients based on prede- 
fined criteria and the Initial interventions are sent Upon selection specif k; predefined program activrties take place. 
30 [01 62] A sample initiation might be tiiat 1 ) a letter Is sent, on behalf of the patient, to their physidan informing tiiem 
of this patient's identification into tiie program, the dteease protocols and the recommended actions from tiie physician. 
2) Intervention Management data Is passed from the Disease Management database 120 to the Intervention Manage- 
ment system 160 and is loaded. 3) An Initial "contact segment" is added for the patient indicating the sending of ttie phy- 
sician letter. 

35 [0163] Another sample initiation might be: 1) a letter is sent to the patient, with a copy to their physician informing 
them of tiieir induskm in the disease program. 2) The patient may be requested to call into a Vok:e Response System 
to answer specific questions. 3) The contact is added and the responses analyzed for further processing. 
[01 64] The second step of the process te tiie Enrollment step 1 320. In ttite step tiie Patients are enrdled into tiie pro- 
gram. Patients are enrolled into ttie Disease Management service ttirough interfeces to ttie Intervention Management. 

40 System. These interfeces can be through a Voice Response System, written letter return or a direct call. The enrollment 
process triggers ttie scheduling of an Intervention event wlttiin ttie intervention management system. 
[0165] The next st^ Is the Intervention process 1330, which is ttie process of Interceding with a physician and dient 
for ttie purposes of: 1) ensuring compliance witti a course of treatment 2) providing disease educational material to 
botti the patient and physician. 3) providing emergency asstetance from a distance. 3) logging each and every interven- 

45 tion as a "contact" to provkJe assistance In determining program effectiveness and to estaWteh a framework to make 
mid-course adjustments to ttie program, and 4) provkiing data back to the product managers on program effectiveness. 
[01 66] The last step te ttie analytic process 1 340 whfch assimilates disease information fbr ttie purposes of determin- 
ing disease management sendee success. Although the inten^ention management system does not produce ttie ana- 
lytk; reporting, critical infonnation is passed back during ttiis process to ttie Disease Management Database 120 fbr 

so processing. 

[0167] While ttie Invention has been desaibed in ternis of an exemplary embodiment it is contemplated ttiat it may 
be practiced as outiined above wrtti modifications ttiat are wittiin ttie scope of the following daims. 

Claims 

55 

1. A computer-inrplemented method for disease or condition Intervention management using infamation about 
patients existing in at least one database, said mettiod comprising ttie steps of: 
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a) prcxiessing. based on predetermined criteria, the patient information In the database to extract patient infor- 
mation for a group of patients relating to an identified disease or condition: 

b) defining a predictive model, including: 

i) defining, using the information available in the database, a set of events or data relevant to the identified 
disease or condition; 

ii) converting the extracted patient infonnation and the defined events or data into files comprising event- 
level information: 

iii) defining a time-window for providing a timeframe from which to judge whether specific ones of the 
defined events should be considered in subsequent processing; 

iv) identifying a set of variables as potential predictors: 

v) processing the event-level information, using the time-window and the set of variables, to generate an 

analysis file: 

vi) performing statistical analysis on the analysis file to generate the prediction model and a set of rules for 
use in identifying at-risk patients diagnosed with or who may develop the identified disease or condition, 
said prediction model and rules being a function of a subset of the set of variables; 

c) applying the prediction model and the rules to the same or new set of event-level information to identify at- 
risk patients for tiie identified disease or condition, or to identify patients who may be at risk for developing ttie 
identified disease or condition: 

d) preparing an intervention list from the identified at-risk patients and selecting, for at least one at risk patient, 
an intervention; 

e) distributing or facilitating ttie distribution of the intervention to said patient; and optionally 

f) recording and tracking an intervention result for each at-risk patient based on ttie respective selected inter- 
vention: and optionally 

g) updating ttie historical data in at least one database witti each Inten^ention result oonresponding to sakj data- 
base; and 

h) repeating step b(ii); and 

I) re-applying ttie prediction nfKXiel and rules to ttie event-level information extracted from ttie data in ttie 
updated database. 

A computer-implemented system for disease management using information about patients existing in a database, 
said system conrprising: 

a) processing means for processing, based on predetermined criteria, ttie patient information in ttie database 
to extract patient infbrmation for a group of patients having an Mentified disease or condition; 

b) means for defining a predictive model, including: 

i) event definition means for defining, using ttie information available in the database, a set of events rele- 
vant to ttie identified disease or condition: 

ii) conversfon means for converting ttie extracted patient Information and the defined events into files con- 
taining event-level information; 

iii) means for defining a time window for providing a timeframe from which to judge whettier specific ones 
of ttie defined events should be considered in subsequent processing; 

iv) means defining a set of variables as potential predictors: 

v) means for processing ttie event-level infbmiation. using ttie time window and ttie set of variables, to gen- 
erate an analysis file; 

vi) means for performing statistical analysis on ttie analysis file to generate ttie prediction model and a set 
of rules for use in identifying at-risk patients diagnosed wItti ttie identified disease, said predkiion model 
and rules being a function of a subset of ttie set of variables; 

c) means for applying ttie prediction model and the rules to ttie same or new set of event-level Infbrmation to 
identify at-risk patients for ttie identified disease or condition; 

d) means for forming an intervention list from tiie klentif led at-risk patients and selecting, fbr at least one at risk 
patient, an intervention; 

e) means for distributing or facilitating ttie distribution of ttie inten/ention to said patient; and optionally 

f) means for recording and tracking an intervention result for each at-risk patient based on the respective 
selected intervention; and 



22 



EP 0 917 078 A1 



g) means for updating the historical data in at least one database with each intervention result corresponding 
to said database or creating a min^or database using the data obtained in step f); and 

h) means Ibr repeating step b(i): and 

i) means for re-applying the prediction nrxxiel and rules to the event-level infonmation extracted from the data 
in the updated database. 

A process for preparing a health intervention product from patient information in a computer database said process 
comprising: 

a) using a computer for extracting and processing, based on predetermined criteria, the patient information in 
the database to obtain a data file of patient information for a group of patients having an Identified disease or 
condition; 

b) programming a predictive rrxxjel into a computer wherein the model constructed includes the steps of: 

i) defining, using the information available in the database, a set of events relevant to the identified disease 
or condition; 

ii) converting the extracted patient information and the defined events into files containing event-level infor- 
mation: 

iii) applying a time window for providing a timeframe from which to judge whether specific ones of the 
defined events should be considered in subsequent processing; 

iv) entering a set of variables as potential predictors; 

v) generating an analysis file by processing the event-level infonratlon. using the time window and the set 
of variables; 

vi) performing statistical analysis on the analysis file to generate the prediction nxxiel and a set of rules for 
use in identifying at-risk patients diagnosed with the identified disease or condition, said prediction model 
and rules being a function of a subset of the set of variables; then 

on a computer: 

c) running tiie prediction model and the rules against the same or new set of event-level Information to identify 
at-risk patients tor ttie identified disease or condition; 

d) outputting an intervention list from the identified at-risk patients and selecting, for at least one at risk patient, 
an Intervention; 

e) distributing the intervention to said patient; and optionally 

f) recording and tracking an inten/ention result for each at-risk patient based on the respective selected inter- 
vention; and 

g) updating ttie historical data in at least one database or creating a new database with each intervention result 
con^esponding to said database; and 

h) re-running step b(i); and 

i) re-running the prediction model and rules against the event-level information extracted from the data in the 
database aeated in step g; and optionally 

D outputting an intervention list obtained re-running ttie prediction model and the rules against the database 
created in step g. 

A health intervention product made by the process of: 

a) using a computer for extracting and processing, based on predetermined criteria, the patient information In 
the database to obtain a data file of patient informatioo for a group of patients having an kJentified disease or 
condition; 

b) programming a predfotive nrxxiel into a computer wherein the model constructed includes the steps of: 

0 defining, using the information available in the database, a set of events relevant to tiie identified disease 
or condition; 

ii) converting the extiBcted patient information and the defined events into files containing event-level infor- 
mation; 

iii) applying a time window for providing a timeframe from which to judge whether specific ones of ttie 
defined events should be considered in subsequent processing; 

iv) entering a set of variables as potential predictors; 

v) generating an analysis file by processing the event-level infomnation. using the time window and the set 
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of variables; 

vi) pertorming statistical analysis on the analysis file to generate the prediction model and a set of rules for 
use in identifying at-risk patients diagnosed with the identified disease or condition, said prediction model 
and rules being a function of a subset of the set of variables: then 
on a computer: 



c) running the prediction model and the rules against the same or new set of event-level information to identify 
at-risk patients for the identified disease or condition; 

d) outputting in hard copy or machine-readable form an intervention list from the identified at-risk patients and 
selecting, for at least one at risk patient, an intervention; 

e) distributing the intervention to said patient: and opttonaily 

f) recording and tracking an inten/ention result for each at-risk patient based on the respective selected inter- 
vention; and 

g) updating the histaical data in at least one database or creating a new database with each intervention result 
con-esponding to said database: and 

h) re-running step b(i): and 

i) re-running the prediction model and rules against the event-level information extracted from the data in the 
database aeated in step g; and optionally 

j) oulputting an inten/ention list obtained by re-running the prediction nrxxlel and the rules against the database 
created in step g. 
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